I. Field
The present invention generally relates to packet data communications, and more particularly, to initial communication sessions prior to establishing packet data communications for network access.
II. Background
Interconnecting of networks globally allows information to be swiftly accessed irrespective of geographical distances. FIG. 1 shows a simplified schematic drawing of the global connection of networks, commonly referred to as the Internet signified by the reference numeral 20. The Internet 20 is in essence many networks with different levels of hierarchy linked together. The Internet 20 is operated under the IP (Internet Protocol) promulgated by the IETF (Internet Engineering Task Force). Details of the IP can be found in RFC (Request For Comments) 791 published by the IETF.
Connected to the Internet 20 are various individual networks, sometimes called LANs (Local Area Networks) or WANs (Wide Area Networks) depending on the network sizes. Shown in FIG. 1 are some of such networks 22, 24 and 26.
Within each of the networks 22, 24, and 26, there can be various pieces of equipment connected to and in communication with each other. Examples are computers, printers, and servers, to name just a few, which are commonly called nodes. When a node communicates beyond its own network via the Internet 20, an IP address needs to be assigned to the node. The assignment of the IP address can be manual or automatic. The manual assignment of the IP address can be performed by a network administrator, for example. More often, the IP address is automatically assigned, for instance, by a dedicated server in the LAN.
Take an example for illustration. Suppose a node 30 in the network 22 attempts to send a data packet to another node 34 in the network 24. Under the IP, each data packet needs to have a source address and a destination address. In this case, the source address is the address of the node 30 in the network 22. The destination address is the address of the node 34 in the network 24.
Very often, node-to-node communications are required prior to network access, such as the Internet 20. For instance, suppose the node 30 in the network 22 is a laptop computer. The laptop computer node 30 has no direct access to the network 22. Nevertheless, the laptop computer node 30 may reach a NAS (Network Access Server) 32 in the network 22 via some other means, such as by dialing up a wired modem though a telephone line, for example. In that case, the node 30 typically establishes a PPP (Point-to-Point Protocol) session with the NAS (Network Access Server) 32 in the network 22. Packet data communications thereafter established between the node 30 and the network 22, or any other networks via the Internet 20, will be exchanged through the wired modem and the telephone line. If the modem transmits and receives signals serially and asynchronously through the telephone line, data packets exchanged over the telephone line also have to be framed accordingly to suit the serial and asynchronous modem link.
Advent in wireless technologies allows nodes to move away from their originally registered network to another network. For instance, referring back to FIG. 1, the node 30, instead of permanently wired to the network 22, can be a wireless device, such as a PDA (Personal Device Assistant), a cellular phone, or a mobile computer. The wireless node 30 can travel beyond the boundary of its home network 22. Thus, the node 30 may roam away from its home network 22 to a foreign network 26. To gain access of the network 26, or to be connected to other networks via the Internet 20, the node 30 also typically establishes a PPP session with a NAS (Network Access Server) 33 in the network 26. Communications between the node 30 and the NAS 33 in this case are through the air link. Again, data packets exchanged between the node 30 and the wireless network also have to be framed to fit into the format which is negotiated during the PPP session between the node 30 and the NAS 33 through the air link.
The bulk of the PPP is described in RFCs 1661 and 1662 published by the IETF. The PPP is a peer-to-peer protocol in which both nodes are peers. That is, neither party assumes the role of a client nor a server. Either party can request actions from or perform actions to the other. In essence, the PPP is an exploratory and negotiating session between nodes, during which session, the nodes find out from each other's resources in terms of capability and availability and finally converge to a set of mutually acceptable parameter options, prior to any network traffic flow.
FIG. 2 shows a sequence flow diagram of an exemplary PPP communication session 34 in which the node 30 in the network 26 seeks to establish a link with the NAS 32 for gaining access to the Internet 20.
The PPP has a number of protocol components. In the exemplary PPP session shown in FIG. 2, the PPP has a LCP (Link Control Protocol) 36, a CHAP (Challenge/Handshake Authentication Protocol) 38, and a IPCP (Internet Protocol Configuration Protocol) 40 as components.
First, upon completion of the physical link, that is, the node 30 and the NAS 33 are capable to reach each other at the hardware level, for example, there is a need to go through the LCP 36. The LCP 36 serves the purpose of establishing the basic communication link between the node 30 and the NAS 33. During the LCP 36, the node 30 and the NAS 33 exchange and negotiate essential communication parameter options with each other. The options can include, maximum size of the data packet through the link, parameters relating to quality control, HDLC (High Level Data Link Control) header field compression scheme used, and whether the peer is willing to be authenticated.
The processes for the LCP 36 are more or less operated under a handshake etiquette. First, the requesting party proposes one or more parameters by sending a Configure Request message. If any parameter is not recognized by the receiving party, the receiving party responds back with a Configure Reject message. If the rejected parameter is fatal to the sought link, the requesting party then has to terminate the PPP session.
On the other hand, if the parameter is recognized but the option related to the parameter is not acceptable, the responding party sends back a Configure Nak message. The requesting party again can either terminate the PPP session or send another Configure Request message with a different option for the same parameter.
As mentioned earlier, the PPP is a peer-to-peer protocol. Either the node 30 or the NAS 33 can be the requesting party. The same holds true for the role of the responding party. All parameters with the associated options have to be negotiated and settled in manner as described above. Several rounds of negotiation may be required, as shown in FIG. 2. The overall negotiation scheme is basically a simplex process. If the requesting party determines that all the parameters needed are acceptable to the responding party, the requesting party sends a final Configure Ack message to the responding party. Once both parties have sent Configure Ack messages, they then transition to the authentication phase.
To ensure the parties are authorized, authentication has to be carried out. One way to perform authentication is to use the other PPP component CHAP 38. It is typically the NAS 33 that initiates the CHAP 38 to verify the identity of the node 30. During the CHAP 38, the NAS 33 sends a message called a challenge message to the node 30. Under the CHAP, there is a shared secret which is used along with the challenge message that is used to calculate a response message using a pre-agreed upon algorithm. The node 30 then sends the response message generated by the secret algorithm to the NAS 33. The NAS 33 thereafter compares the received response message with the message calculated by the NAS 33 itself. If there is a comparison match, the node 30 is said to pass the CHAP 38 in which the NAS 33 sends a CHAP Success message to the node 30. Otherwise, a CHAP Failure message is sent by the NAS 33.
Alternatively, instead of the CHAP 38, authentication can be accomplished by going through a PAP (Password Authentication Protocol). In the PAP, the node merely sends the NAS 33 a username and password for verification. If verified, the node 30 is said to pass the PAP.
If the node 30 needs IP access, information relating to IP again needs to be exchanged and negotiated. For example, among other things, the node 30 may need to have an assignment of an IP address in order to access the Internet 20 (FIG. 1) in accordance with the IP. To accomplish this end, negotiation and exchange of parameter options under the IPCP 40 commence. In the exemplary PPP session 34, the node 30 initially requests an IP address 0.0.0.0 from the NAS 33. In response, the NAS 33 sends a Configure Nak message, suggesting the node 30 use the IP address a.b.c.d. If accepted, the node 30 confirms the use of the IP address a.b.c.d by sending the NAS 33 another message for acknowledgement.
Finally, when the node 30 agrees to all the parameters negotiated during the IPCP 40, the node 30 sends an acknowledge message to the NAS 33. User data of the network access session are thereafter exchanged. The IP data packets of the network traffic are encapsulated into the PPP frames with parameters and negotiated during the LCP 36 earlier.
At the end of the network access, either the node 30 or the NAS 33 may send a Terminate Request message to the other, which thereafter responds back with a Terminate Ack message and conclude the communication session.
As can be seen in FIG. 2 and described above, there are quite a number of messages exchanged between the node 30 and the NAS 33 during the PPP session 34. As such, considerable time duration is involved. This is especially true if the PPP session 34 is negotiated over a slow link with high data latency.
Accordingly, there is need to provide a faster and more efficient way of establishing initial communication links prior to any next levels of data traffic.